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APPELLANT'S BRIEF 

Commissioner for Patents: 

This brief is in furtherance of the Notice of Appeal, filed in this case on June 10, 201 1, 
and in response to the Final Office Action mailed on March 10, 201 1, the Advisory Action 
mailed on May 24, 201 1, and the decision on the Pre -Appeal Brief Request for Review mailed 
on August 2, 201 1 . The fees required under Section 41 .20(b)(2), and any required request for 
extension of time for filing this brief and fees therefor, are dealt with in the accompanying 
transmittal letter. 
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I. REAL PARTY IN INTEREST 

The real party in interest is ST-Ericsson SA, which has an address at 39 Chemin du Champ 
des Filles, 1228 Plan-Les-Outes, Geneva, CH. 
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II. RELATED APPEALS AND INTERFERENCES 

Appellant, Appellant's legal representative, and the real party in interest are unaware of 
any appeal or interference which may be related to, directly affect, be directly affected by, or 
have a bearing on the Board's decision in the present appeal. Appellant notes that an appeal was 
previously filed in this case, but was dismissed after Appellant filed a Request for Continued 
Examination. 
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III. STATUS OF CLAIMS 

Claims 1-23 are pending and stand rejected. All pending active claims are attached 
hereto as an Appendix, and reflect the amendment entered by the Examiner for purposes of 
appeal. 

Claims 1, 3-8, 10-20 and 22 stand rejected under 35 U.S.C. 103(a) as obvious over U.S. 
Patent Application Publication No. 2004/0264397 Al by Benveniste in view of U.S. Patent No. 
7,724,691 issued to Rogers. Claims 2, 9, 21 and 23 stand rejected under 35 U.S.C. 103(a) as 
obvious over Benveniste and Rogers in view of U.S. Patent Application Publication No. 
2003/0126244 Al by Smith et al. 

The rejections of claims 1-23 are appealed. 

It is noted that the Final Office Action mailed March 10, 201 1, rejected claims 18-21 
under 35 U.S.C. Section 101 as directed to non-statutory subject matter. Appellant submitted an 
Amendment After Final on May 10, 201 1, amending claims 18-21. For purposes of appeal, in an 
Advisory Action mailed on May 24, 201 1, the Examiner entered the amendments to claims 18- 
21 and withdrew the rejection of claims 18-21 under 35 U.S.C. Section 101. 
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IV. STATUS OF AMENDMENTS 

An amendment after the Final Office Action was submitted on May 10, 201 1 . The 
amendments to the claims addressed a rejection of claims 18-21 under 35 U.S.C. Section 101. 
The Examiner entered the amendments to claims 18-21 for purposes of appeal in an Advisory 
Action mailed on May 24, 201 1, in which the Examiner withdrew the Section 101 rejections and 
disagreed with the arguments made in response to the Final Office Action with regard to the art- 
based rejections. The Examiner is thanked for entering the amendment for purposes of appeal 
and for withdrawing the Section 101 rejections. 
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V. SUMMARY OF CLAIMED SUBJECT MATTER 

The application is a conversion of PCT Application No. PCT/IB04/52343 filed 
November 8, 2004 into a U.S. National Application. 

The present application includes 4 independent claims, all of which are being appealed. 
The following summary discusses the subject matter of the independent appealed claims along 
with citations to corresponding portions of the specification and drawings per 37 C.F.R. § 
41.37(c)(l)(v). The citations below are provided to illustrate specific examples and 
embodiments of the recited language, and are not intended to limit the claims. None of the 
independent claims involved in the appeal or dependent claims argued separately includes means 
plus function elements or steps plus function elements as permitted by 35 U.S.C. § 1 12, sixth 
paragraph, and thus no corresponding summaries related to such means plus function elements or 
step plus function elements are included. 

It is believed that the claimed invention will be more easily understood if some 
embodiments shown in the figures of the present application are discussed first. Following that 
discussion is a presentation of the independent claims with reference to the figures and 
specification. Of course, the parentheticals shown in claims 1,8, 18 and 22 are intended to show 
support for the claimed elements, and are not intended to limit the claims only to the 
embodiments referenced in the parentheticals. 

Figures 4 through 6 illustrate embodiments of methods of determining when to provide 
service to client devices operating in power save mode in a wireless network. Figure 4 appears 
below. 
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FIGURE 4 

As illustrated, a service request is received from a client at 410. A determination is then 
made at 420 as to whether the request is for scheduled service or for unscheduled service. This 
may be done by setting a schedule bit in the service request, as illustrated in Figure 3B, which 
appears below. 
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FIGURE 3B 



7 



If the request is for scheduled service, the request may then be processed according to the 
embodiment of a method set forth in Figure 5, reproduced below. 




FIGURE 5 

As illustrated, it is determined whether the request for scheduled service will be accepted 
at 5 10. If the request is accepted, it will be provided as requested or provided under a modified 
schedule, and the client will be provided with an indication of the schedule under which the 
service will be provided. See 460, 465 and 470. If the request is denied, the denial will be 
recorded and the client will be provided with an indication that the request has been denied. See 
520, 530. 
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If the request is for unscheduled service, the request may be processed according to the 
embodiment of a method set forth in Figure 6, reproduced below. 




FIGURE 6 

As illustrated, it is determined whether to honor the request for non-scheduled service 
(430). If the request is to be honored, the client is provided with an indication that the request 
will be accommodated (435). If it is not to be honored, it will be determined whether the request 
will be accepted (630). If the request is not accepted, the client will be provided with an 
indication that it was not accepted (530). If the request is to be accepted, a schedule will be set 
up and the client will be provided with an indication that the request will be accommodated with 
a schedule (440, 450). 
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Figure 7, reproduced below, illustrates a system 700 in a wireless network which is 
configured to determine when to provide service to client devices 701 . The system includes a 
processor which, for example, is configured to execute instructions to carry out methods of 
determining when to process client requests, such as the methods illustrated in Figures 4-6. 




FIGURE 7 
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Independent Claim 1 : 

Independent claim 1 is directed to a method to determine in a network component (Fig. 7, 
700) when to provide service to client devices (Fig. 7, 701) operating in power-saving mode in a 
wireless network (Fig. 7), the method comprising: 

receiving requests for service from respective ones of said client devices (Figs. 4-6, 410), 
the received requests for service including a request for scheduled service received from a first 
one of the client devices (Figs. 4 and 5, 460) and a request for unscheduled service received from 
a second one of the client devices (Figs. 4 and 6, 430), said network component being informed 
of said request for scheduled service by a field of a traffic specification format being set to a first 
value (Fig. 3a, TS INFO; Fig. 3b, SCHEDULE; Figs. 4-6, 420; page 4, paragraphs 20 and 21), 
said network component being informed of said request for unscheduled service by said field of 
said traffic specification format being set to a second value different from said first value (Fig. 
3a, TS INFO; Fig. 3b, SCHEDULE; Figs. 4-65, 420; page 4, paragraphs 20 and 21); 

determining an ability to accommodate said received requests for service (Fig. 4, 460, 
465, 430; Fig. 5, 510, 460, 465; Fig. 6, 430, 630; page 4, paragraph 21 to page 5, paragraph 23; 
page 6, paragraphs 27 and 28); and 

providing respective indications of the ability to accommodate said received requests for 
service to the first and second ones of said client devices (Fig. 4, 470, 450, 435; Fig. 5, 470, 530; 
Fig. 6, 530, 450, 435; page 4, paragraph 21 to page 5, paragraph 26; page 6, paragraphs 27-29). 
(See also Figures 3a through 6 and the descriptions thereof on pages 4-6). 
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Independent Claim 8: 

Independent claim 8 is directed to a device (Fig 7, 700) to determine when to provide 
service to client devices (Fig. 7, 701) operating in power-saving mode in a wireless network (Fig. 
7), said device comprising: 

a memory (Fig. 7, 704); 

a processor (Fig. 7, 703) in communication with said memory, said processor operable to 
execute code to: 

receive requests for service from respective ones of said client devices (Figs. 4-6, 410; 
page 8, paragraph 34), the received requests including a request for scheduled service received 
from a first one of the client devices (Figs. 4 and 5, 460) and a request for unscheduled service 
received from a second one of the client devices (Figs. 4 and 6, 430), said device being informed 
of said request for scheduled service by a field of a traffic specification format being set to a first 
value (Fig. 3a, TS INFO; Fig. 3b, SCHEDULE; Figs. 4-6, 420; page 4, paragraphs 20 and 21), 
said device being informed of said request for unscheduled service by said field of said traffic 
specification format being set to a second value different from said first value (Fig. 3a, TS INFO; 
Fig. 3b, SCHEDULE; Figs. 4-65, 420; page 4, paragraphs 20 and 21); 

determine an ability to accommodate said received requests for service (Fig. 4, 460, 465, 
430; Fig. 5, 510, 460, 465; Fig. 6, 430, 630; page 4, paragraph 21 to page 5, paragraph 23; page 
6, paragraphs 27 and 28); and 

provide respective indications of the ability to accommodate said received requests for 
service to the first and second ones of said client devices (Fig. 4, 470, 450, 435; Fig. 5, 470, 530; 
Fig. 6, 530, 450, 435; page 4, paragraph 21 to page 5, paragraph 26; page 6, paragraphs 27-29). 
(See also Figures 3a through 7 and the descriptions thereof on pages 4-8). 
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Independent Claim 18: 

Independent claim 18 is directed to a processing device (Fig. 7, 703) within a network 
component (Fig. 7, 700) to determine an ability of said network component to honor requests for 
service received from respective client devices (Fig. 7, 701), said processing device being 
configured to cause the network component to: 

review, under control of the processing device, an operating state of said network 
component (Figs. 4-6, 430, 465, 510, 630; page 4, paragraph 21; page 5, paragraphs 23, 25 and 
26; page 6, paragraph 27); 

review, under control of the processing device, said requests for service (Figs. 4-6, 410; 
page 8, paragraph 34), the requests for service including requests for scheduled service and 
requests for unscheduled service, said network component being informed of said requests for 
scheduled service by a field of a traffic specification format being set to a first value (Fig. 3a, TS 
INFO; Fig. 3b, SCHEDULE; Figs. 4-6, 420; page 4, paragraphs 20 and 21), said network 
component being informed of said requests for unscheduled service by said field of said traffic 
specification format being set to a second value different from said first value (Fig. 3a, TS INFO; 
Fig. 3b, SCHEDULE; Figs. 4-65, 420; page 4, paragraphs 20 and 21); 

cause, under control of the processing device, the network component to accommodate 
said requests for service, with modification when necessary, when said operating state indicates 
that said requests for service are able to be accommodated (Fig. 4, 465, 440, 450, 435; Fig. 5, 
465; Fig. 6, 440, 450, 435; page 8, paragraph 34; page 12, original claim 18); and 

provide respective indications of said accommodation to said first and second one of the 
client devices (Fig. 4, 470, 450, 435; Fig. 5, 470, 530; Fig. 6, 530, 450, 435; page 4, paragraph 
21 to page 5, paragraph 26; page 6, paragraphs 27-29). (See also Figures 3a through 7 and the 
descriptions thereof on pages 4-8). 1 



Appellant has noted an antecedent basis error in claim 18, and Appellant will work with the Examiner on remand 
to address the error. 
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Independent Claim 22: 

Independent claim 22 is directed to a non-transitory computer readable media (Fig. 7, 
704, 787, 783; page 7, paragraph 32 to page 8, paragraph 33) whose contents cause a processor 
(Fig. 7, 703; page 7, paragraph 32 to page 8, paragraph 33) to execute instructions to cause a 
network component (Fig. 7, 700) to: 

receive requests for service from client devices (Figs. 4-6, 410; page 8, paragraph 34), the 
received requests including requests for scheduled service and requests for unscheduled service 
from the client devices (Figs. 4-6, 430, 460); 

become informed of a request for scheduled service based on a field of a traffic 
specification format being set to a first value (Fig. 3a, TS INFO; Fig. 3b, SCHEDULE; Figs. 4-6, 
420; page 4, paragraphs 20 and 21); 

become informed of a request for unscheduled service by said field of said traffic 
specification format being set to a second value different from said first value (Fig. 3a, TS INFO; 
Fig. 3b, SCHEDULE; Figs. 4-6, 420; page 4, paragraphs 20 and 21); 

determine an ability to accommodate said received requests for service (Fig. 4, 460, 465, 
430; Fig. 5, 510, 460, 465; Fig. 6, 430, 630; page 4, paragraph 21 to page 5, paragraph 23; page 
6, paragraphs 27 and 28); and 

provide respective indications of the ability to accommodate said received requests for 
service to the respective client devices (Fig. 4, 470, 450, 435; Fig. 5, 470, 530; Fig. 6, 530, 450, 
435; page 4, paragraph 21 to page 5, paragraph 26; page 6, paragraphs 27-29). (See also Figures 
3a through 7 and the descriptions thereof on pages 4-8). 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

1. Whether claims 1, 3-8, 10-20 and 22 are unpatentable under 35 USC Section 
103(a) as obvious over U.S. Patent Application Publication No. 2004/0264397 Al by Benveniste 
in view of U.S. Patent No. 7,274,691 issued to Rogers. 

2. Whether claims 2, 9, 21 and 23 are unpatentable under 35 USC Section 103(a) as 
obvious over Benveniste and Rogers in view of U.S. Patent Application Publication No. 
2003/0126244 Al by Smith et al. 
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VII. ARGUMENT 

The Examiner initially bears the burden of establishing a prima facie case of 
unpatentability. In re Bell, 26 U.S.P.Q.2d 1529 (Fed. Cir. 1993); In re Oetiker, 
977 F.2d 1443, 1445, 24 U.S.P.Q.2d 1443, 1444 (Fed. Cir. 1992); In re Piasecki, 
745 F.2d 1468, 1472, 223 U.S.P.Q. 785, 788 (Fed. Cir. 1984); MPEP § 2142. 

An obviousness rejection may be attacked by showing that the Examiner has failed to 
properly establish a prima facie case or by presenting evidence tending to support a conclusion 
of non-obviousness. In order to find prima facie obviousness when combining references, 
MPEP § 2143(A)(1) states the following (emphasis ours): "Office personnel must articulate the 
following: (1) a finding that the prior art included each element claimed , although not necessarily 
in a single prior art reference, with the only difference between the claimed invention and the 
prior art being the lack of actual combination of the elements in a single prior art reference." 
MPEP § 706.02(j) further states (emphasis ours): "To support the conclusion that the claimed 
invention is directed to obvious subject matter, either the references must expressly or impliedly 
suggest the claimed invention or the examiner must present a convincing line of reasoning as to 
why the artisan would have found the claimed invention to have been obvious in light of the 
teachings of the references. Ex parte Clapp, 227 USPQ 972, 973 (Bd. Pat. App. & Inter. 1985)." 
See also In re Thrift and Hemphill, 298 F.3d 1357, 1366 (Fed. Cir. 2002) (for an examiner to 
establish a prima facie case that an invention, as defined by a claim at issue, is obvious the 
examiner must: (1) show some suggestion or motivation, either in the references themselves or in 
the knowledge generally available to one of ordinary skill in the art, to modify the reference or 
combine the reference teachings; (2) there must be a reasonable expectation of success; and (3) 
the prior art reference (or the combined references) must teach or suggest all the claim 
limitations); MPEP § 2142. Moreover, a reference must be viewed as a whole, including 
portions that would lead away from the claimed invention. MPEP § 2141.02 (citing W.L. Gore 
& Assoc., Inc. v. GarlocK Inc., 721 F.2d 1540, 220 U.S.P.Q. 303 (Fed. Cir. 1983). If the 



16 



proposed modification would change the principles of operation of the prior art invention being 
modified, then the teachings of the references are not sufficient to render the claims prima facie 
obvious. MPEP § 2143.01 (citing In re Ratti, 270 F.2d 810, 123 U.S.P.Q. 349 (CCPA 1959)). 

The U.S. Supreme Court case, KSR Int'l Co. v. Teleflex, Inc., 550 U.S. 398 (2007), does 
not change the requirement for an examiner to provide such evidence of motivation. "The 
teaching or suggestion to make the claimed combination and the reasonable expectation of 
success must both be found in the prior art, not in applicant's disclosure." MPEP § 2143. The 
level of skill in the art cannot be relied upon to provide the suggestion to combine the references. 
MPEP § 2143.01 (citing Al-Site Corp. v. VSI Int'l Inc., 174 F.3d 1308, 50 U.S.P.Q.2d 1161 (Fed. 
Cir. 1999). The mere fact that the references can be combined or modified does not render the 
resultant combination obvious unless the prior art also suggests the desirability of the 
combination. MPEP § 2143.01 (citing In re Mills, 916 F.2d 680, 16 U.S.P.Q. 2d 1430 (Fed. Cir. 
1990). 

A. Claims 1-7 Are Not Rendered Obvious by Benveniste, Considered Alone or in 
Combination With Rogers and Smith 

Independent claim 1 recites, "[a] method to determine in a network component when to 
provide service to client devices operating in power-saving mode in a wireless network, said 
method comprising: receiving requests for service from respective ones of said client devices, the 
received requests for service including a request for scheduled service received from a first one 
of the client devices and a request for unscheduled service received from a second one of the 
client devices, said network component being informed of said request for scheduled service by a 
field of a traffic specification format being set to a first value, said network component being 
informed of said request for unscheduled service by said field of said traffic specification format 
being set to a second value different from said first value ..." 

The Examiner concedes that Benveniste does not disclose the recited "said network 
component being informed of said request for scheduled service by a field of a traffic 
specification format being set to a first value, said network component being informed of said 
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request for unscheduled service by said field of said traffic specification format being set to a 
second value different from said first value." The Examiner points to Column 10, lines 35-43 of 
Rogers. The cited portion of Rogers instead refers to identifying packets as part of a particular 
real-time application packet flow using header fields. There is no mention of using a field of 
traffic specification format to indicate whether a request for service is a request for scheduled 
service or a request for unscheduled service. Further, Rogers appears to be completely unrelated 
to devices operating in a power-saving mode. The Examiner does not argue that Smith provides 
the missing teachings. Accordingly, Benveniste, considered alone or in combination with 
Rogers and Smith, does not render claim 1 obvious at least because the references do not 
disclose "said network component being informed of said request for scheduled service by a field 
of a traffic specification format being set to a first value, said network component being 
informed of said request for unscheduled service by said field of said traffic specification format 
being set to a second value different from said first value," as recited. The Examiner provides no 
reasoned explanation why one of skill in the art would have found the required further 
modifications to the combination of Benveniste, Rogers and Smith to be obvious. In response to 
the above arguments, the Examiner states as follows: 

25. Applicant argues: "The cited portion of Rogers instead refers to identifying 
packets as part of a particular real-time application packet flow using header fields. 
There is no mention of using a field of traffic specification format to indicate whether a 
request for service is a request for scheduled service or request for unscheduled 
service" (pg 8, lines 16-20). 

Examiner respectfully disagrees. Rogers deals with the scheduling of packet 
flows to provide guaranteed bandwidth (Col. 6, lines 27-52). Real-time packets of 
Rogers are packets associated with delivery delay limit guarantees (Rogers, Col. 10, 
lines 30-31). The real-time packets are sent according to a predetermined, allocated 
schedufe (Rogers, Col. 10, lines 42-43). The packet flow associated with a real-time 
application (or an application with delivery delay limit guarantees) is identified by packet 
header field values that are common to all packets in the flow (Rogers, Col. 10, lines 35- 
38). Therefore, in Rogers there are packet header values that are different between a 
scheduled packet flow and unscheduled packets. Rogers uses the packet header 
values (a field of traffic specification format) to differentiate between scheduled and 
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unscheduled packet flows (indicate whether a request for service is a request for 
scheduled service or request for unscheduled service). 



The cited portions of Column 10 of Rogers upon which the Examiner relies are 
reproduced below: 



30 The transmission of packets associated with delivery and 
deJay limit guarantees, referred to as real-time packets, is 
now described. Such packets may, for example, be associ- 
ated with real-time applications. The association between a 
real-time packet and a real-time application may^ for 

35 example^ be through packet flow. A packet flow associated 
with a real-time application may be identified by some set of 
packet header field values that are common to ah packets 
within the packet flow. Real-time packets may also be 
handled by the switch 2, For example, processing of real- 

40 time packets sent by the host 1 to the switch 2 requires that 
the host 1 coordinate its guaranteed transmissions with the 
switch 2, The host 1 will further send its real-time packets 
in accordance with a predetermined, allocated schedule. In 



Thus, as previously argued, the cited portion of Rogers discusses identifying packets as 
part of a particular real-time application packet flow using header fields. There is no mention of 
using a field of traffic specification format of a request for service , for any reason, let alone to 
indicate whether the request for service is a request for scheduled service or a request for 
unscheduled service. To the extent the Examiner contends Rogers inherently discloses the 
missing feature based on the reference to coordinating between the host and the switch, 
evidentiary support was respectfully requested, and was not provided. It is noted that inherency 
is not shown merely because a reference could be modified to include a missing feature. 

In the Advisory Action, the Examiner points to disparate portions of Rogers that (i) 
mention real-time packet flows may be scheduled (Column 12, lines 12-28) and (ii) discuss using 
header values to identify packets as part of a previously scheduled real-time packet flow. The 
Examiner then apparently reasons (without citing any evidentiary support) that a packet that 
identifies itself as part of a previously scheduled particular real-time application packet flow 
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using any combination of header field values identifies itself as a request for scheduled service 
using those fields. 

Assuming for the sake of argument that a packet using one or more fields to identify itself 
as part of a previously scheduled real-time packet flow somehow discloses "said network 
component being informed of said request for scheduled service by a field of a traffic 
specification format being set to a first value," this does not mean that Rogers would also 
disclose "said network component being informed of said request for unscheduled service by 
said field of said traffic specification format being set to a second value different from said first 
value." For example, the one or more fields of the previously scheduled packets of Rogers could 
have different values for any number of reasons, such as to indicate they are part of another 
previously scheduled real-time packet flow. 

Accordingly, the Examiner has not established a prima facie case that claim 1 is rendered 
obvious by Benveniste, considered alone or in combination with the other references. Thus, 
claim 1 is allowable. Claims 2-7 depend from claim 1 and are allowable at least by virtue of 
their dependencies, as well as because of the novel and non-obvious combinations claimed 
therein. 

B. Claims 8-17 Are Not Rendered Obvious by Benveniste, Considered Alone or in 
Combination With Rogers and Smith 

Independent claim 8 recites, "said device being informed of said request for scheduled 
service by a field of a traffic specification format being set to a first value, said device being 
informed of said request for unscheduled service by said field of said traffic specification format 
being set to a second value different from said first value." The Examiner concedes this 
functionality is not disclosed by Benveniste. The Examiner points to Rogers, Col. 10, lines 35- 
43. The cited portion of Rogers, however, discusses identifying packets as part of a particular 
real-time application packet flow using header fields. There is no mention of using a field of 
traffic specification format to indicate whether a request for service is a request for scheduled 
service or a request for unscheduled service. Further, Rogers appears to be completely unrelated 
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to devices operating in a power-saving mode. The Examiner does not contend that Smith 
provides the missing teachings. Accordingly, Benveniste, considered alone or in combination 
with Rogers and Smith, does not render claim 8 obvious at least because the references do not 
disclose "said device being informed of said request for scheduled service by a field of a traffic 
specification format being set to a first value, said device being informed of said request for 
unscheduled service by said field of said traffic specification format being set to a second value 
different from said first value," as recited. The Examiner provides no reasoned explanation why 
one of skill in the art would have found the required further modifications to the combination of 
Benveniste, Rogers and Smith to be obvious. 

In response to the above arguments, the Examiner states as follows: 

25. Applicant argues: The cited portion of Rogers instead refers to identifying 
packets as part of a particular real-time application packet flow using header fields. 
There is no mention of using a field of traffic specification format to indicate whether a 
request for service is a request for scheduled service or request for unscheduled 
service" (pg 8, lines 16-20). 

Examiner respectfully disagrees. Rogers deals with the scheduling of packet 
flows to provide guaranteed bandwidth (Col. 6, lines 27-52). Real-time packets of 
Rogers are packets associated with delivery delay limit guarantees (Rogers, Col. 10, 
lines 30-31). The real-time packets are sent according to a predetermined, allocated 
schedule (Rogers, Col. 10, fines 42-43). The packet flow associated with a real-time 
application (or an application with delivery delay limit guarantees) is identified by packet 
headerfield values that are common to all packets in the flow (Rogers, CoL 10, lines 35- 
38). Therefore, in Rogers there are packet header values that are different between a 
scheduled packet flow and unscheduled packets. Rogers uses the packet header 
values (a field of traffic specification format) to differentiate between scheduled and 

unscheduled packet flows (indicate whether a request for service is a request for 
scheduled service or request for unscheduled service). 

The cited portions of Column 10 of Rogers upon which the Examiner relies are 
reproduced below: 
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30 The transmission of packets associated with delivery and 
delay limit guarantees, referred to as real-time packets, is 
now described. Such packets may, for example, be associ- 
ated with real-time applications. The association between a 
real-tinie packet and a real-time application may, for 

35 example, be through packet flow. A packet flow associated 
with a real-time application may be identified by some set of 
packet header field values that are common to all packets 
within the packet flow. Real-time packets may also be 
handled by the switch 2. For example, processing of real- 

4G time packets sent by the host 1 to the switch 2 requires that 
the host i coordinate its guaranteed transmissions with the 
switch 2. The host I will further send its real-time packets 
in accordance with a predetermined, allocated schedule. In 



Thus, as previously argued, the cited portion of Rogers discusses identifying packets as 
part of a particular real-time application packet flow using header fields. There is no mention of 
using a field of traffic specification format of a request for service , for any reason, let alone to 
indicate whether the request for service is a request for scheduled service or a request for 
unscheduled service. To the extent the Examiner contends Rogers inherently discloses the 
missing feature based on the reference to coordinating between the host and the switch, 
evidentiary support is respectfully requested. It is noted that inherency is not shown merely 
because a reference could be modified to include a missing feature. 

In the Advisory Action, the Examiner points to disparate portions of Rogers that (i) 
mention real-time packet flows may be scheduled (Column 12, lines 12-28) and (ii) discuss using 
header values to identify packets as part of a previously scheduled real-time packet flow. The 
Examiner then apparently reasons (without citing any evidentiary support) that a packet that 
identifies itself as part of a previously scheduled particular real-time application packet flow 
using any combination of header field values identifies itself as a request for scheduled service 
using those fields. 

Assuming for the sake of argument that a packet using one or more fields of a header to 
identify itself as part of a previously scheduled real-time packet flow somehow discloses "said 
device being informed of said request for scheduled service by a field of a traffic specification 
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format being set to a first value," this does not mean that Rogers would also disclose "said device 
being informed of said request for unscheduled service by said field of said traffic specification 
format being set to a second value different from said first value." For example, the one or more 
fields of the previously scheduled packets of Rogers could have different values for any number 
of reasons, such as to indicate they are part of another previously scheduled real-time packet 
flow. 

Accordingly, the Examiner has not established a prima facie case that claim 8 is rendered 
obvious by Benveniste, considered alone or in combination with the other references. Thus, 
claim 8 is allowable. Claims 9-17 depend from claim 8 and are allowable at least by virtue of 
their dependencies, as well as because of the novel and non-obvious combinations claimed 
therein. 

C. Claims 18-21 Are Not Rendered Obvious by Benveniste, Considered Alone or in 
Combination With Rogers and Smith 

Independent claim 18 recites, "review . . . said requests for service, the requests for 
service including requests for scheduled service and requests for unscheduled service, said 
network component being informed of said requests for scheduled service by a field of a traffic 
specification format being set to a first value, said network component being informed of said 
requests for unscheduled service by said field of said traffic specification format being set to a 
second value different from said first value." The Examiner concedes Benveniste does not 
disclose "said network component being informed of said requests for scheduled service by a 
field of a traffic specification format being set to a first value, said network component being 
informed of said requests for unscheduled service by said field of said traffic specification format 
being set to a second value different from said first value." The Examiner points to Rogers, Col. 
10, lines 35-43. The cited portion of Rogers, however, discusses identifying packets as part of a 
particular real-time application packet flow using header fields. There is no mention of using a 
field of traffic specification format to indicate whether a request for service is a request for 
scheduled service or a request for unscheduled service. The Examiner does not contend that 
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Smith provides the missing teachings. Accordingly, Benveniste, considered alone or in 
combination with Rogers and Smith, does not render claim 18 obvious at least because the 
references do not disclose "said network component being informed of said requests for 
scheduled service by a field of a traffic specification format being set to a first value, said 
network component being informed of said requests for unscheduled service by said field of said 
traffic specification format being set to a second value different from said first value," as recited. 
The Examiner provides no reasoned explanation why one of skill in the art would have found the 
required further modifications to the combination of Benveniste, Rogers and Smith to be 
obvious. 

In response to the above arguments, the Examiner states as follows: 

25. Applicant argues: The cited portion of Rogers instead refers to identifying 
packets as part of a particular real-time application packet flow using header fields. 
There is no mention of using a field of traffic specification format to indicate whether a 
request for service is a request for scheduled service or request for unscheduled 
service" (pg 8, lines 16-20). 

Examiner respectfully disagrees. Rogers deals with the scheduling of packet 
flows to provide guaranteed bandwidth (Col. 6, lines 27-52). Real-time packets of 
Rogers are packets associated with delivery delay limit guarantees (Rogers, Col. 10, 
lines 30-31). The real-time packets are sent according to a predetermined, allocated 
schedule (Rogers, Col. 10, fines 42-43). The packet flow associated with a real-time 
application (or an application with delivery delay limit guarantees) is identified by packet 
headerfield values that are common to all packets in the flow (Rogers, CoL 10, lines 35- 
38). Therefore, in Rogers there are packet header values that are different between a 
scheduled packet flow and unscheduled packets. Rogers uses the packet header 
values (a field of traffic specification format) to differentiate between scheduled and 

unscheduled packet flows (indicate whether a request for service is a request for 
scheduled service or request for unscheduled service). 

The cited portions of Column 10 of Rogers upon which the Examiner relies are 
reproduced below: 
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30 The transmission of packets associated with delivery and 
delay limit guarantees, referred to as real-time packets, is 
now described, Such packets may, for example, be associ- 
ated with real-time applications. The association between a 
real-time packet and a real-time application may, for 

35 example, be through packet flow. A packet flow associated 
with a real-time application may be identified by some set of 
packet header field values that are common to all packets 
within the packet flow* Real-time packets may also be 
handled by the switch 2, For example, processing of real- 

40 time packets sent by the host 1 to the switch 2 requires that 
the host 1 coordinate its guaranteed transmissions with the 
switch 2* The host I wii! further send its real-time packets 
in accordance with a predetermined, allocated schedule. In 



Thus, as previously argued, the cited portion of Rogers discusses identifying packets as 
part of a particular real-time application packet flow using header fields. There is no mention of 
using a field of traffic specification format of a request for service , for any reason, let alone to 
indicate whether the request for service is a request for scheduled service or a request for 
unscheduled service. To the extent the Examiner contends Rogers inherently discloses the 
missing feature based on the reference to coordinating between the host and the switch, 
evidentiary support is respectfully requested. It is noted that inherency is not shown merely 
because a reference could be modified to include a missing feature. 

In the Advisory Action, the Examiner points to disparate portions of Rogers that (i) 
mention real-time packet flows may be scheduled (Column 12, lines 12-28) and (ii) discuss using 
header values to identify packets as part of a previously scheduled real-time packet flow. The 
Examiner then apparently reasons (without citing any evidentiary support) that a packet that 
identifies itself as part of a previously scheduled particular real-time application packet flow 
using any combination of header field values identifies itself as a request for scheduled service 
using those fields. 

Assuming for the sake of argument that a packet using one or more fields of a header to 
identify itself as part of a previously scheduled real-time packet flow somehow discloses "said 
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network component being informed of said requests for scheduled service by a field of a traffic 
specification format being set to a first value," this does not mean that Rogers would also 
disclose "said network component being informed of said requests for unscheduled service by 
said field of said traffic specification format being set to a second value different from said first 
value." For example, the one or more fields of the previously scheduled packets of Rogers could 
have different values for any number of reasons, such as to indicate they are part of another 
previously scheduled real-time packet flow. 

Accordingly, the Examiner has not established a prima facie case that claim 18 is 
rendered obvious by Benveniste, considered alone or in combination with the other references. 
Thus, claim 18 is allowable. Claims 19-21 depend from claim 18 and are allowable at least by 
virtue of their dependencies, as well as because of the novel and non-obvious combinations 
claimed therein. 

D. Claims 22 and 23 Are Not Rendered Obvious by Benveniste, Considered Alone 
or in Combination With Rogers and Smith 

Independent claim 22 recites, "become informed of a request for scheduled service based 
on a field of a traffic specification format being set to a first value; become informed of a request 
for unscheduled service by said field of said traffic specification format being set to a second 
value different from said first value." The Examiner concedes Benveniste does not disclose 
"become informed of a request for scheduled service based on a field of a traffic specification 
format being set to a first value; become informed of a request for unscheduled service by said 
field of said traffic specification format being set to a second value different from said first 
value." The Examiner points to Rogers, Col. 10, lines 35-43. The cited portion of Rogers, 
however, discusses identifying packets as part of a particular real-time application packet flow 
using header fields. There is no mention of using a field of traffic specification format to 
indicate whether a request for service is a request for scheduled service or a request for 
unscheduled service. The Examiner does not contend that Smith provides the missing teachings. 
Accordingly, Benveniste, considered alone or in combination with Rogers and Smith, does not 
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render claim 22 obvious at least because the references do not disclose "become informed of a 
request for scheduled service based on a field of a traffic specification format being set to a first 
value; become informed of a request for unscheduled service by said field of said traffic 
specification format being set to a second value different from said first value," as recited. The 
Examiner provides no reasoned explanation why one of skill in the art would have found the 
required further modifications to the combination of Benveniste, Rogers and Smith to be 
obvious. 

In response to the above arguments, the Examiner states as follows: 

25. Applicant argues: The cited portion of Rogers instead refers to identifying 
packets as part of a particular real-time application packet flow using header fields. 
There is no mention of using a field of traffic specification format to indicate whether a 
request for service is a request for scheduled service or request for unscheduled 
service" (pg 8, lines 16-20). 

Examiner respectfully disagrees. Rogers deals with the scheduling of packet 
flows to provide guaranteed bandwidth (Col. 6, lines 27-52). Real-time packets of 
Rogers are packets associated with delivery delay limit guarantees (Rogers, Col. 10, 
lines 30-31). The real-time packets are sent according to a predetermined, allocated 
schedule (Rogers, Col. 10, fines 42-43). The packet flow associated with a real-time 
application (or an application with delivery delay limit guarantees) is identified by packet 
headerfield values that are common to all packets in the flow (Rogers, CoL 10, lines 35- 
38). Therefore, in Rogers there are packet header values that are different between a 
scheduled packet flow and unscheduled packets. Rogers uses the packet header 
values (a field of traffic specification format) to differentiate between scheduled and 

unscheduled packet flows (indicate whether a request for service is a request for 
scheduled service or request for unscheduled service). 

The cited portions of Column 10 of Rogers upon which the Examiner relies are 
reproduced below: 
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30 The transmission of packets associated with deli very and 
delay limit guarantor referred to as real-time packets, is 
now described, Such packets may, for example, be associ- 
ated with real-time applications. The association between a 
real-time packet and a real-time application may, for 

35 example, be through packet flow. A packet flow associated 
with a real -time application may be identified by some set of 
packet header field values that are common to all packets 
within the packet flow. Real-time packets may also be 
handled by the switch 2, For example, processing of real- 

40 time packets sent by the host 1 to the switch 2 requires that 
the host 1 coordinate its guaranteed transmissions with the 
switch 2. The host I will further send its real-time packets 
in accordance with a predetermined, allocated schedule. In 



Thus, as previously argued, the cited portion of Rogers discusses identifying packets as 
part of a particular real-time application packet flow using header fields. There is no mention of 
using a field of traffic specification format of a request for service , for any reason, let alone to 
indicate whether the request for service is a request for scheduled service or a request for 
unscheduled service. To the extent the Examiner contends Rogers inherently discloses the 
missing feature based on the reference to coordinating between the host and the switch, 
evidentiary support is respectfully requested. It is noted that inherency is not shown merely 
because a reference could be modified to include a missing feature. 

In the Advisory Action, the Examiner points to disparate portions of Rogers that (i) 
mention real-time packet flows may be scheduled (Column 12, lines 12-28) and (ii) discuss using 
header values to identify packets as part of a previously scheduled real-time packet flow. The 
Examiner then apparently reasons (without citing any evidentiary support) that a packet that 
identifies itself as part of a previously scheduled particular real-time application packet flow 
using any combination of header field values identifies itself as a request for scheduled service 
using those fields. 

Assuming for the sake of argument that a packet using one or more fields of a header to 
identify itself as part of a previously scheduled real-time packet flow somehow discloses 
"become informed of a request for scheduled service based on a field of a traffic specification 
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format being set to a first value," this does not mean that Rogers would also disclose "become 
informed of a request for unscheduled service by said field of said traffic specification format 
being set to a second value different from said first value." As discussed above, the one or more 
fields of the previously scheduled packets of Rogers could have different values for any number 
of reasons, such as to indicate they are part of another previously scheduled real-time packet 
flow. 

Accordingly, the Examiner has not established a prima facie case that claim 22 is 
rendered obvious by Benveniste, considered alone or in combination with the other references. 
Thus, claim 22 is allowable. Claim 23 depends from claim 22 and is allowable at least by virtue 
of its dependency, as well as because of the novel and non-obvious combination claimed therein. 

E. Conclusion of Argument 

The Examiner has failed to establish a prima facie case that the claims are anticipated or 
rendered obvious by Benveniste, whether considered alone or in combination with Rogers and 
Smith. Accordingly, the Examiner's rejections cannot be sustained and reversal of the Examiner's 
rejections is respectfully requested. 
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VIII. CLAIMS APPENDIX 



1 . A method to determine in a network component when to provide service to client 
devices operating in power-saving mode in a wireless network, said method comprising: 

receiving requests for service from respective ones of said client devices, the received 
requests for service including a request for scheduled service received from a first one of the 
client devices and a request for unscheduled service received from a second one of the client 
devices, said network component being informed of said request for scheduled service by a field 
of a traffic specification format being set to a first value, said network component being 
informed of said request for unscheduled service by said field of said traffic specification format 
being set to a second value different from said first value; 

determining an ability to accommodate said received requests for service; and 
providing respective indications of the ability to accommodate said received requests for 
service to the first and second ones of said client devices. 

2. The method as recited in claim 1, further comprising, in response to being unable 
to accommodate the request for unscheduled service, providing a proposed service schedule to 
the second one of the client devices. 

3. The method as recited in claim 1, wherein said request for scheduled service 
includes a proposed service schedule. 

4. The method as recited in claim 3, further comprising modifying said proposed 
service schedule. 
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5. The method as recited in claim 4, further comprising providing said modified 
proposed service schedule to said first one of the client devices. 

6. The method as recited in claim 1, wherein said indications are selected from a 
group consisting of: denied, accommodated with change, and accommodated. 

7. The method as recited in claim 1, wherein said determining the ability to 
accommodate is based on at least one factor selected from a group consisting of: a requested 
servicing method, a proposed schedule, network operating state, network policy, and network 
condition. 

8. A device to determine when to provide service to client devices operating in 
power-saving mode in a wireless network, said device comprising: 

a memory; 

a processor in communication with said memory, said processor operable to execute code 

to: 

receive requests for service from respective ones of said client devices, the received 
requests including a request for scheduled service received from a first one of the client devices 
and a request for unscheduled service received from a second one of the client devices, said 
device being informed of said request for scheduled service by a field of a traffic specification 
format being set to a first value, said device being informed of said request for unscheduled 
service by said field of said traffic specification format being set to a second value different from 
said first value; 

determine an ability to accommodate said received requests for service; and 
provide respective indications of the ability to accommodate said received requests for 
service to the first and second ones of said client devices. 
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9. The device as recited in claim 8, wherein said processor is further operable to 
execute said code to, in response to being unable to accommodate the request for unscheduled 
service, provide a proposed service schedule to the second one of the client devices. 

10. The device as recited in claim 8, wherein said request for scheduled service 
includes a proposed service schedule. 

1 1 . The device as recited in claim 10, wherein said processor is further operable to 
execute said code to: modify said proposed service schedule. 

12. The device as recited in claim 11, wherein said processor is further operable to 
execute said code to: provide said modified service schedule to said first one of the client 
devices. 

13. The device as recited in claim 8, wherein said indications are selected from a 
group consisting of: denied, accommodated with change, and accommodated. 

14. The device as recited in claim 8, wherein said determine said ability to 
accommodate is based on at least one factor selected from a group consisting of: a requested 
servicing method, a proposed schedule, network operating state, network policy, and network 
condition. 

15. The device as recited in claim 8, further comprising: an I/O device operable as an 
interface between said network and said processor. 

16. The device as recited in claim 8, wherein said code is stored in said memory. 
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17. The device as recited in claim 8, further comprising: 
a receiving device to receive said requests; and 

a transmitting device to provide said respective indications to the first and second ones of 
said client devices. 

18. A processing device within a network component to determine an ability of said 
network component to honor requests for service received from respective client devices, said 
processing device being configured to cause the network component to: 

review, under control of the processing device, an operating state of said network 
component; 

review, under control of the processing device, said requests for service, the requests for 
service including requests for scheduled service and requests for unscheduled service, said 
network component being informed of said requests for scheduled service by a field of a traffic 
specification format being set to a first value, said network component being informed of said 
requests for unscheduled service by said field of said traffic specification format being set to a 
second value different from said first value; 

cause, under control of the processing device, the network component to accommodate 
said requests for service, with modification when necessary, when said operating state indicates 
that said requests for service are able to be accommodated; and 

provide respective indications of said accommodation to said first and second one of the 
client devices. 

19. The processing device as recited in claim 18 wherein said processing device is 
further configured to cause the network component to: 

provide respective indications of denying said requests for service to the respective client 
devices when said operating state indicates that said requests for service are unable to be 
accommodated. 
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20. The processing device as recited in claim 18, wherein said operating state is 
selected from a group consisting of: processing load, demand, projected processing load, 
projected demand, network component operating state, network component policy, and network 
component condition. 

21. The processing device as recited in claim 18 wherein said processing device is 
further adapted to cause the network component to, in response to being unable to accommodate 
a request for unscheduled service, provide a proposed service schedule to the respective client 
device. 

22. A non-transitory computer readable media whose contents cause a processor to 
execute instructions to cause a network component to: 

receive requests for service from client devices, the received requests including requests 
for scheduled service and requests for unscheduled service from the client devices; 

become informed of a request for scheduled service based on a field of a traffic 
specification format being set to a first value; 

become informed of a request for unscheduled service by said field of said traffic 
specification format being set to a second value different from said first value; 

determine an ability to accommodate said received requests for service; and 

provide respective indications of the ability to accommodate said received requests for 
service to the respective client devices. 

23. The non-transitory computer readable media of claim 22 wherein execution of the 
instructions further causes the network component to, in response to being unable to 
accommodate a request for unscheduled service, provide a proposed service schedule to the 
respective client device. 
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EVIDENCE APPENDIX 
None. 



X. RELATED PROCEEDINGS APPENDIX 
None. 
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